kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/newsgroups/misc.19980424-19980901/000298_news@newsmaster….columbia.edu _Sun Jul 26 11:19:29 1998.msg

Internet Message Format | 1998-08-31 | 9KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA25031
    for <[e-mail]>; Sun, 26 Jul 1998 11:19:28 -0400 (EDT)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA01729
    for kermit.misc@watsun; Sun, 26 Jul 1998 11:19:28 -0400 (EDT)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Xenix to 5.0.4 Data Transfer ? Stay with UUCP
Followup-To: comp.protocols.kermit.misc,comp.unix.sco.misc
Date: 26 Jul 1998 15:19:26 GMT
Organization: Columbia University
Lines: 187
Message-ID: <6pfhdu$ch9$[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9006

>From: [e-mail] (Jeff Liebermann)
Newsgroups: comp.unix.sco.misc
Subject: Re: Xenix to 5.0.4 Data Transfer ? Stay with UUCP
Date: Sat, 25 Jul 1998 16:47:53 GMT
Organization: Committee To Maintain an Independent Xenix

On Fri, 24 Jul 1998 06:48:40 GMT, [e-mail] (Klaus ter Fehn)
wrote:

>I totally disagree and so here are some 'pro's for UUCP:

Good analysis. I partially disagree and here are my comments.
Please note that this is in response to a Xenix to OSR5 file
transfer question.

>1. It's standard. I know of no UNIX distribution which does not include
>   at least an old UUCP implementation.

Kermit is available for just about every known operating system
including some rather dead ones.  Zmodem is available as part of
most terminal emulators.  UUCP was an optional module on Xenix
and could be un-installed.  I've blundered into small-office
installations where UUCP was removed in an effort to obtain
diskspace.

>2. It's reliable. Once a Job is queued UUCP will repeatedly retry
>   transmitting the data. Everything is done automatically, success
>   or failure can be reported via Email. In case of complete failure
>   data is kept in /usr/spool/uucp/.Failed - so no data is lost and
>   can be re-spooled.

Correct, although the Xenix mechanism is different.  Xenix UUCP
simply reports the failure but does not save the remains.  UUCP
also has the irritating habit of first performing the file copy
to /usr/spool/uucp/system_name, and only then determining if it
has permission to scribble to the destination directory.  If not,
it declares an error and erases the copied file.  Kermit and
zmodem are at least smart enough to check BEFORE transfering
files.

>3. It's failsave. Properly configured UUCP can automatically switch to
>   alternate transport media (for example switching from TCP to Modem
>   transfer). This may be very important if your ISP is down (hi AT&T :)

That's very useful for daily email traffic but is of little
importance when copying files between two local machines.  I
would never consider using kermit or zmodem for handling my
email.

>4. Automatic Job execution. Properly configured UUCP can execute remote
>   jobs after the file transfer has succeeded and optionally send
>   results back.

Yes.   That's the way usenet news via UUCP works.  There was a
time when I was using UUCP to do remote tape backups and
printing.  Please note that the same things can be done with
kermit in the server mode and zmodem run from a shell script.
Again, this has no relivance for file transfer between Xenix and
OSR5.

>5. Multiple protocols and login-handshake guarantee that UUCP will use
>   the appropiate protocol to the neighbour system. When s.o. says UUCP
>   is slow, his problems may lie in his UUCP configuration. Maximum
>   block sizes and transport windows can be configured at least with
>   SVR4-HDB-UUCP and Taylor-UUCP.

Protocol, window size and packet length are adjustable on most
versions of UUCP.  Some use Configuration files.  Others require
patching.  Some uucico incantations (early 3.2v4.x) will die
horribly by accepting 1KB packets and 7 packet windows, but
refusing to properly send in this configuration.  The selection
of protocols is from a sequential list.  uucico will pick the
FIRST matching protocol without the slightest consideration for
line speed and error rate.  In short, UUCP can be manually
configured to optimize performance.  Zmodem and Kermit adjust
window size and packet length continuously and automagically.

>6. For some people this is important: It's even available for (shudder)
>   DOS (I don't know of other OSes).

Yep.  UUPC.  See:
    http://www.kew.com/UUPC.download.htm
However, zmodem and kermit are also available for MSDOS.

>7. It's easy to maintain. OK, a clever UUCP layout may be difficult in
>   the first step (like everything one tries for the first time). But if
>   the links are properly configured you can forget about it. Most
>   problems people report aren't UUCP problems at all: proper modem
>   setup is by far the most difficult thing (If you use modems at all -
>   remember - UUCP can be used over TCP/IP, too).

This may be important for a permanent installation that does
regular file transfers.  Maintenance is important.  However, I
find that UUCP initial setup to be far more complex than kermit
or zmodem.  For example, kermit can be configured and run
interactively to establish optimum parameters and settings.
Pro-Yam (zmodem) can do the same.  UUCP has no interactive
configuration and must be manually configured.

UUCP over tcp/ip works quite well.  However, UUCP, zmodem and
kermit all mangle the permissions and ownership of copied files.
If you're going to use TCP, you might as well use rcp to do the
copying.  It's faster and much easier.

>Stay with UUCP. If you have the time (1 day) you can install Taylor-
>UUCP, which has some nice goodies, like easy to read configuration
>files, lots of implemented protocols and transfer resume after an
>interrupted call.

The transfer will "resume" by starting over.  This is not a
problem if you're moving small files but a major issue if the
files are large.  Some implimentations of zmodem and kermit will
recognize an aborted tranfer and continue from where they left
off instead recopying the entire file.

>If you use modems I recommend mgetty, since it is the
>most reliable getty for dialin/dialout modem communications and can even
>deal with nasty modems who tend forget their settings once in a while.

Well, I've played with about 2000 modems in the last 15 years and
have never seen one that would "forget" its setting that could
not be attributed to a dialer or comm programming making the
changes.  This was especially true with early releases of
3.2v5.0.0(???) that had AT&W (save settings) in the modem dialer
initialization strings or certain Windoze FAX dialers that would
leave the modem in a useless state.  If there are modems that
lose their settings, I would be interested in identifying them.
Note that there are modems that have no NVRAM and therefore have
no way to save their settings.  Whenever there are more than one
program accessing a modem, there is a serious risk that what one
program considers acceptable settings may not be useable to the
others.

>As a free bonus you'll get a fax solution, too. Both are freely
>available as source and as binaries for different platforms.

Kermit can do TAP alpha emulation and paging.

What's necessary here is some perspective.  Each communications
program has its strengths and weaknesses.  These depend upon what
one is attempting to accomplish.  For a Xenix to OS5 transfer,
the relative differences of each approach are marginal.  This is
probably a one time ordeal and maximum efficiency is of little
benifit.  Your analysis is more applicable to a permanent
installation involving shared modem(s) and requireing features
beyond a simple file transfer.

[x]email  [x]news  [ ]mailing list
--
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
[phone] pgr [phone] fax [phone] home
http://www.cruzio.com/~jeffl   WB6SSY
[e-mail]   [e-mail]

>From: [e-mail] (Frank da Cruz)
Newsgroups: comp.unix.sco.misc
Subject: Re: Xenix to 5.0.4 Data Transfer ? Stay with UUCP
Date: 26 Jul 1998 14:45:55 GMT
Organization: Columbia University

In article <[e-mail]>,
Jeff Liebermann <[e-mail]> wrote:
: ...
: UUCP over tcp/ip works quite well.  However, UUCP, zmodem and
: kermit...
:
and FTP...

: ... all mangle the permissions and ownership of copied files.
:
C-Kermit 6.1 (now in Beta):

  http://www.columbia.edu/kermit/ck61.html

preserves permissions when transferring files UNIX-to-UNIX, and also
to some degree for inter-platform transfers, when the other platform
also supports the notion of permissions (e.g. UNIX-VMS).

: If you're going to use TCP, you might as well use rcp to do the
: copying.  It's faster and much easier.
:
And if the connection breaks in the middle of rcp'ing a huge file,
you can use C-Kermit (or Zmodem) to complete the transfer from the point
of interruption, provided the partial file was not discarded on the
target end.

- Frank